Many modern electronic devices, e.g. handheld devices such as portable/hand-held communications devices, e.g. mobile telephones, communicators, pagers, or other portable/hand-held devices such as personal digital assistants, personal entertainment devices, such as mp3 players, etc., are controlled by software stored in flash memory. For the purpose of the present description, software stored in a persistent memory of an electronic device that controls operation of, or runs on the electronic device such that during normal operation of the electronic device it cannot be stopped and/or started separately from the electronic device as a whole will be referred to as firmware. Hence, the firmware may be regarded as forming the software core of the system on which it runs. In addition to the firmware, other software may be stored and executed on the electronic device; such other software may generally be started and stopped by a user of the electronic device during normal operation of the electronic device, separately from the start-up/shut-down of the electronic device and the firmware. An electronic device controlled by firmware stored in persistent memory of said electronic device is also referred to as embedded device or embedded system, and the firmware is referred to as being embedded into the electronic device. Even though the firmware of an electronic device is typically not changed during normal operation of the device, updates of the firmware may be desirable or even necessary during the lifetime of an electronic device, e.g. in order to install new functionality, update existing functionality, correct errors in the firmware, and/or the like. It will be appreciated that an electronic device may have stored thereon further software components, such as application software, that provide additional functionality to a user of the electronic device but which are not required for the operation of the electronic device.
An update of the firmware of an electronic device involves a number of specific problems e.g. when compared to a software update of a personal computer:
To update an application on a personal computer, that application must normally be stopped if it is running. The update is then performed by overwriting the installed application files with new versions. The core operating system (OS) does not generally contain any dedicated update software. Updates are performed by running an application which performs the necessary changes to the system. To update active parts of the software, e.g. the OS itself, a reboot is required to complete the process. Where there are post reboot actions required, the application is scheduled to be started after the reboot. This process is not inherently crash safe. If the update is interrupted the application will be broken and the user must take actions to repair it.
Embedded devices on the other hand often use flash memory for persistent storage, because it allows multiple rewrites. Flash memory generally includes memory sectors, and write and/or read operations of the flash memory are typically performed in multiples of such memory sectors. When the firmware stored in a flash memory of an electronic device is updated, e.g. in order to add new features to the software and/or to correct errors in the current version of the firmware, some or all of the memory sectors of the flash memory are re-written/re-programmed (this process is often referred to as “re-flashing”). Any space for user data will typically be partitioned separately from the firmware, and there is normally no space available for complete copies of the firmware image, so updates are typically performed ‘in place’. The new version of the firmware is typically written over the top of the old version. During the update process the firmware stored in persistent memory will be partly the old firmware and partly the new firmware. Trying to execute the firmware in this state would produce unpredictable results at best, and most likely a crash.
An embedded system will generally be running a real time operating system. Simple systems may not run an operating system at all. Unlike on a personal computer, all the firmware is active during operation of the embedded system and it is not possible to close an application that is part of the firmware in order to update it. If any part of such an embedded system crashes, the whole system crashes. Due to these limitations, the update process should be designed to be fail-safe, or an interruption to the update will result in a broken device.
In particular, an application where reliability of the update process is of great concern is the over-the-air (OTA) update of communications devices such as mobile terminals, i.e. an update where the updated software is received from a remote update system via a cellular communications network. The over-the-air update of the firmware of such a communications device is also referred to as Firmware-Over-The-Air (FOTA) update.
WO 03/025742 discloses a method of updating software in a remote device, where the software stored on the device is partitioned into a boot partition, a core firmware partition, and an auxiliary software partition. During a software update, the auxiliary software partition is initially overwritten by the updated version of the core firmware. In a next step, the device is rebooted with the new core firmware, and the updated auxiliary software is downloaded and written on top of the old core firmware. Even though this process allows an update of the software of an electronic device that has not enough memory for an entire additional copy of the software, this process requires a complete update of the entire software in order to again reach a fully operational state. It would thus be desirable to provide a more efficient update process that requires less download time and/or bandwidth. Furthermore, the above prior art process depends on its ability to re-connect to the host from which the software update is downloaded after the reboot or at least after a power loss or other interruption of the update process so as to download the auxiliary software. If the process fails to reconnect to the host, the device is left in an inoperational state. It thus remains a problem to provide an update process that has a higher degree of fail-safety.